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Description 
Technical Field 

5 [0001] This invention relates to exchanging data over a telecommunications network, and more particularly to cus- 
tomizing the application protocol by which users of a telecommunications network communicate with the network. 

Background of the Invention 

10 [0002] As telecommunications network subscribers seek to optimize their use of the many electronic communication 
services available to them, there is an increasing demand for networks that can be customized to fit each subscriber's 
particular needs. Currently, most communications are performed over public networks using standard communication 
protocols. 

[0003] The standard communication protocols that are used on most public networks consist essentially of a set of 
15 coding rules that characterize the data to be exchanged over the networks. 

[0004] Once the rules are known, data can be encoded and decoded by network users without ambiguity. A drawback 
of using standardized protocols is that they cannot be redefined and/or customized according to a user's individual 
needs without making changes to the user's software. 

[0005] The current state of the art in telecommunications requires network users to modify their software to accom- 
20 modate changes in the communication protocols. For example, a bank may have a system in place that allows its 
customers to request account information over the telephone. The bank's system prompts the customer to select a 
service and the customer depresses one or more Touch Tone™ buttons to supply a response. The bank's computer 
is programmed to carry out one or more steps in response to each customer request, such as sending a fax when the 
customer enters a "1", or sending a voice message when the customer enters a "2". This type of system, however, is 
25 limited to the preprogrammed responses contained in the bank's software. If the bank would like to modify its system 
to handle new types of information requests, the bank would have to modify the system software accordingly. One way 
around this problem would be to have a network operator (such as AT&T) provide an adaptable interface between the 
customer and the bank. An adaptable interface would allow users to redefine the form of their business communications 
without incurring the losses of time and money normally associated with modifying their network interfaces. Accordingly, 
30 a capability to customize protocols is highly desirable to network users, and, in turn, to the network operators seeking 
to attract those users. 

[0006] EP^A-0 621 714 discloses a system for reducing the cost of calls, typically 800 number calls to an information 
source, by transforming a voice connection at an originating toll switch into a data connection to the desired information 
source. The toll switch is coupled to a service platform including a plurality of Universal Access Nodes (UAN) linked 

35 to the information source via a packet network and a service node. When a call is received by the platform, the calling 
information includes a Dialed Number Identification Service which identifies the type and/or origin of the call. The UAN 
identifies the requested service and the identity of the information source. The UAN presents to the caller an application 
interface that the information source would normally present to the caller. An access module in the UAN converts the 
caller voice signal into a digital signal. An associated CPU translates the digital signal into a message for transmission 

to over the packet network to the service node which unbundles the message and interfaces with the information source. 
The service node forms a message from the information provided by the information source for return to the platform 
via packet network. The CPU working in conjunction with the access modules removes the requested information for 
transmission to the caller in the format requested by the caller. 

45 Summary of the Invention 

[0007] A method and apparatus according to the invention are as set out in the independent claims. Preferred forms 
are set out in the dependent claims. 

50 Summary of the Invention 

[0008] In accordance with the present invention a network service subscriber (such as a bank) tells the operator 
when an incoming message from a caller is expected and the format in which that incoming message should be placed. 
The operator then translates the caller's message into the subscribers's format before relaying the message to the 
55 subscriber. In the same fashion, the subscriber tells the operator when the subscriber expects to send an outgoing 
message to the caller and the format in which outgoing messages will be placed. The operator translates the outgoing 
message into a format the caller understands before relaying the message to the caller. In this manner, the dialog 
between the subscriber and the caller can be varied without modifying either party's interface software. The advantages 
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of such a system are illustrated in the banking example set forth below. 

[0009] By using the present invention a bank may readily customize the communications carried on between the 
bank's computer and the bank's customers. The bank's computer would be provisioned with interface software designed 
to operate with the present invention. Thereafter, to change the bank-customer communication flow, the bank would 

5 inform the network operator of any new types of customer requests that the bank intends to answer, the possible 
responses to those requests, and the format of the requests and responses. The network operator would then use the 
information provided by the bank to modify a database containing the bank-customer communication protocol. The 
implementation of the new communication flow is complete after the database is edited. Thus, the implementation of 
a new bank-customer communication flow involves the mere editing of a database, and neither the bank nor the network 

w operator need modify their respective software. 

[0010] In a preferred embodiment of the invention, a network operator uses a Customer Transaction Profile (CTP) 
Database to store current "protocol definitions" for each subscriber (e.g. the bank). This database is stored on computer 
disk and may be edited at any time to reflect redefinitions of the stored protocols. 

[0011] To setup a protocol, a subscriber provides the network operator with the specifications of the subscriber's 
15 desired protocol. Using these specifications, the operator makes the necessary entries in the CTP database to enable 
customized communication. The subscriber's CTP file may be edited at anytime. Thus, a subscriber desiring to imple- 
ment a new protocol simply provides the operator with new specifications which the operator then uses to edit the CTP 
file and thereby change the protocol. 

[0012] When communication with a subscriber is initiated by a caller, the subscriber's CTP file is loaded from the 
20 disk memory into one of the network's "front end systems" for execution. The front end system reads the file to determine 
an input message format and an output message format, and then uses these formats to translate communications to 
and from the subscriber, respectively. Messages sent from the caller to the subscriber pass through the front end 
system where they are converted into the form specified by the input message format. Messages sent from the sub- 
scriber to the caller are sent in the output message format and converted by the front end system from the output 
25 format to a format that the caller can understand. 

[0013] Using the front end system as a translator allows subscribers and callers to change the form of their commu- 
nications without changing their respective network interfaces. Also, using the CTP to store protocol definitions allows 
subscribers' protocols to be changed without changing the software programs resident at the front end system. 

30 Brief Description of the Drawings 

[0014] 

FIG. 1 is a block-schematic diagram of an illustrative communication system incorporating the present invention. 
35 FIG. 2 is a block-schematic diagram of a communication system incorporating a preferred embodiment of the 

invention. 

FIGs. 3A and 3B make up a flow chart depicting the sequence of operations according to the invention. 

FIG. 4 is a block-schematic diagram showing a configuration of software modules and network servers that may 

be used to implement a preferred embodiment of the invention. 

40 

Detailed Description 

[0015] FIG. 1 is a block diagram of an illustrative embodiment of the present invention. As shown in the figure, the 
illustrative embodiment includes a subscriber 10, a front end system 12, a network 17, and a caller 18. The front end 

45 system may be part of the network or it may be separate from the network, and it may take the form of an electronically 
automated device such as a personal computer, computer workstation, mainframe computer, or microprocessor. For 
illustrative purposes the front end system is shown in figures 1 and 2 as being separate from the network. The software 
necessary to implement the invention is stored in the front end system. This software makes use of data located in a 
Customer Transaction Profile database (CTP) 15 which is located in a disk memory 14 of the front end system 12. 

so [001 6] The CTP contains a separate record for each network subscriber. This record contains instructions concerning 
how the subscriber wants to communicate over the network at the application software level. Whenever a communi- 
cation with the subscriber is initiated, front end system 12 accesses disk memory 14 to locate the subscribers CTP 
record. The record is then loaded into a main memory 16 of the front end system so that the record can be used to 
control the initiated communication session. Since the CTP contains all the necessary information to implement each 

55 subscriber's application protocol, varying the protocol merely requires editing the CTP. 

[0017] In a preferred embodiment the CTP setup procedure involves the following steps. First, the subscriber's busi- 
ness transaction flow and the "business data" to be exchanged over the interface between the network element and 
the subscriber's equipment is analyzed. The results of the analysis are recorded into a "business transaction form," 
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defined by the network operator. The purpose of this form is to ensure adequate information for later use and to prevent 
potential ambiguity. Second, the services (actions) that the network operator will perform to add values and help com- 
plete the subscriber's business transaction(s) are identified. The codes for these services/actions are obtained via a 
"services/actions handbook" provided by the operator (the specific services provided and the way they are activated 

5 are beyond the scope of the present invention). Third, the business transaction form is completed by associating ap- 
propriate services/actions codes with "each" step of a business procedure. Following the third step, the business trans- 
action flow is stitched together and the associated telecommunication services are lined up, ready for use in executing 
the subscriber's transaction flow. Finally, the subscriber is assigned an identification number, or "ID number". 
[0018] A technician "converts" the data recorded in the business transaction form into a Customer Transaction Profile 

10 (CTP) using computer software tools and by entering the data into a provisioning system, a computer system separate 
from the front end system. The provisioning system formats the Profile into a file associated with the subscriber's ID 
number and downloads that file into a front end system. The Profile, after being downloaded into the front end system, 
is "indexed' by the system's advanced intelligent software package for use in processing messages associated with 
the subscriber's ID number. The technician then "turns on" the customer transaction profile in the front end system and 

15 the subscriber is "on-line." Once the subscriber is turned on, the network operator executes the subscriber's business 
transactions according to the agreed upon business data flow. 

[0019] Messages received by the front end system stimulate the intelligent software package to open the appropriate 
subscriber Profile as determined from the subscriber ID number. The messages are "decoded" according to the mes- 
sage specifications recorded in the profile. Network services are then activated by the instructions embedded in the 

20 messages to add values to the subscriber's business transactions. If the subscriber decides to change the business 
transaction flow, a new business transaction form is generated, and the information contained in the form is reflected 
into the subscriber's Customer Transaction Profile. While the CTP is being modified, the existing profile may be "locked" 
so that it is not referenced for call processing before modification is completed. When modification is complete the new 
Profile is turned on and may thereafter be used to process calls. 

25 [0020] As an alternative to having a technician update the CTP 15, updating may be done directly by the subscriber 
10 via a communication coupling 20. Coupling 20, as well as all other communication couplings associated with the 
invention, may be an existing coupling or a customized coupling; and may be in the form of any of the known types of 
communication couplings, such as a standard telephone line, a twisted shielded pair line, a coaxial cable, a fiberoptic 
link, or a wireless link. 

30 [0021] Once the CTP record is setup for a subscriber the communication flow between the caller 18 -any telecom- 
munications device- and the subscriber 10 can proceed. The caller initiates a communication by sending a signal over 
coupling 22 to network 17. The network is coupled to front end system 12 via coupling 30. The front end system 12 
determines which subscriber the call is directed to and loads that subscriber's CTP record into main memory 16. The 
front end system translates the caller's message into an input format that is specified in the CTP record and then 

35 transmits the translated message to the subscriber over coupling 24. 

[0022] If a reply from the subscriber is required, the subscriber transmits the reply to the front end system over 
coupling 26. The reply is in an output format that is specified in the subscriber's CTP record. The front end system 
translates the reply from the output format into a format that can be understood by the caller. Once translated, the reply 
is transmitted to the network over coupling 32 and is relayed to the caller via coupling 28. This information loop from 

40 caller 18 to subscriber 10 and back to caller 18 may be traversed many times during a communication session. 

[0023] In a preferred embodiment, depicted in FIG. 2, a customer will make requests from a bank's computer by 
using Touch Tone™ buttons 64a-641 on the customer's phone. Referring to FIG. 2, there is shown a bank computer 
40, a front end system 50, a network 58, and a bank customer 62. Also depicted in FIG. 2 are block diagram repre- 
sentations of an input message 48 and an output message 66. The input message is in the input message format, the 

45 format into which the front end system will convert messages directed from the customer to the bank computer. The 
output message is in the output message format, the format in which the bank computer will send messages to the 
customer. The front end system must convert the bank computer's output message from the output message format 
to a format that the customer can understand. 

[0024] A typical transaction between the bank 40 and the customer 62 would proceed as follows. The customer dials 
so "ABC Bank's" service hot-line. The customer is connected to the network through a standard telephone coupling 60. 
The network then connects the customer to the front end system - via coupling 55 - so that the front end system can 
perform the front-end business interactions for the ABC Bank 40. A software function in the front end system is activated 
and the dialed number is mapped to a "subscriber ID number" to uniquely identify ABC Bank's CTP record 56. The 
Bank's CTP record is then read from the front end system's disk memory 52 into the front end systems main memory 
55 54 for active operation. 

[0025] A sample CTP record to be used in the present illustration is shown in Table I. 

[0026] The front end system software reads the first instruction specified in the customer's CTP record to start the 
"business transaction execution". Referring to the CTP record shown in Table I, this first instruction would be an an- 
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nouncement, ABC-0. ABC-0 is played to the customer 62: 

(voice) You have reached the ABC Bank's customer service hot line, please make your selection from the 
following menu: 

5 

For your account information, press 1 . 
For an interest rate update, press 2. 
For fund transfer between accounts, press 3. 
To end the call, press 0. 

10 

[0027] The customer makes a selection by pressing one of the Touch Tone™ buttons 64a-641 on the customer's 
telephone. In the present example, the customer selects #1. 

[0028] The front end system software then plays an announcement, ABC-1 -1 , according to the business transaction 
direction recorded in the CTP record: 

15 

(voice) Please enter you account number. 

[0029] The customer responds with the desired account number. 

[0030] The front end system software then plays an announcement, ABC-1 -2: 

20 

(voice) Please enter your PIN number. 
[0031] The customer responds with the PIN number. 

[0032] At this time, the front end system software identifies the "*0" sign from the CTP record. The "*" indicates that 
25 an input message is expected by the ABC Bank and that the ABC Bank will send a reply. The "0" indicates that the 
front end system should go back to instruction ABC-0 and play the main menu again. 

[0033] The front end system formats an input message 48 according to the input message format, ABC-1 -2, specified 
in the customer's CTP record. Two lines within the CTP record define the ABC-1 -2 format; the first line, "ABC-1 -2: 
(2,2,10,10)", setting forth a field size for each field in the format, and the second line, "(Query Bank, selection, account 
30 #, PIN #)", setting forth a field definition for each field in the format. The field sizes are used by the front end system 
to formulate an input message "packet" by which the information from the customer is relayed to the bank. The field 
definitions may be "looked up" by the front end system in a protocol dictionary to determine what action, if any, the 
front end system should take regarding a particular input or output message. 

[0034] One way the protocol dictionary may be implemented is through a "look up table", in which each field definition 
35 is cross referenced to a computer readable code. A more detailed discussion of the protocol dictionary is not necessary 
to completely describe the present invention, and is therefore beyond the scope of this application. 
[0035] In any event, input message format ABC-1-2 consists of the following fields: an X.25 header 68, 2 bytes 
indicating a data base query 70, 2 bytes indicating the customer's selection 72, 10 bytes representing the customer's 
account number 74, and 10 bytes representing the customer's PIN number 76. The X.25 header enables the input 
40 message "packet" to be transmitted over coupling 46 using the X.25 packet switching protocol. It should be understood 
that although the X.25 protocol is used in the described embodiment, there are many other well known protocols, such 
as the Integrated Services Digital Network - Primary Rate Interface (ISDN-PRI) protocol, that may be used to implement 
the invention. It should also be understood that the size of each field (number of bytes) can be customized for each 
subscriber. 

45 [0036] After receiving the input message 48, the bank computer 40 queries its database 42 and formats an output 
message 66 according to the output message format 15, specified in the bank's CTP record. The output message 
consists of: an X.25 header 78, 2 bytes containing a code indicating the front end system service to be performed 80 
- in this example number 15 means text to speech, 8 bytes indicating the transaction ID 82, 4 bytes indicating the length 
of the text to be converted 84 - in this example XX bytes, and XX bytes containing the text to be converted 86. As was 

50 the case with the input message, an X.25 header is needed to transmit the output message "packet" using the X.25 
packet switching protocol. The output message is transmitted over coupling 44. 

[0037] Following transmission of the output message 66 from the bank computer 40 to the front end system 50, the 
front end system converts the account information 86 into speech and plays the speech to the customer 62 via coupling 
55, network 58, and coupling 60. The front end system then plays the main menu, ABC-0, as directed by the "0" in the 
55 "*0" indication. 

[0038] The customer selects #3 to transfer funds from one account to another account. 

[0039] The front end system collects the customer's input and plays an announcement, ABC-3-1 : 
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(voice) Please enter the account number you wish to transfer funds from. 

[0040] The customer enters the "from" account number, XXXXXXXXX. 
[0041] The front end system then plays an announcement, ABC-3-2: 

(voice) Please enter the account number you wish to transfer fund to. 

[0042] The customer enters the "to" account number, YYYYYYYYY. 

[0043] The front end system requests the customer to enter the amount to be transferred, ABC-3-3: 

(voice) Please enter the amount to be transferred. 
[0044] The customer enters the amount, ZZZZZ. 

[0045] The front end system identifies the "*4" sign from the CTP record. In response to the "*" indication, the front 
end system formats an input message according to the ABC-3-3 input format specified in the CTP record (NOTE: the 
ABC-3-3 format is not depicted in FIG. 2). As shown in Table 1, the ABC-3-3 format consists of: 2 bytes indicating a 
fund transfer, 2 bytes indicating the customer's selection, 10 bytes indicating the "from" account number, 10 bytes 
indicating the "to" account number, and 10 bytes indicating the amount to be transferred. The bank computer performs 
the fund transfer and sends a text-to-speech message to the front end system according to output message format 
15. The front end system relays the speech to the customer and then responds to the "4" indication in the "*4" sign. 
[0046] In response to the "4" indication, the front end system announces ABC-4 to the customer: 

(voice) If you need fax confirmation, press 1 . 

If you need paper mail confirmation, press 2. 

[0047] The customer selects 1 and the front end system requests the customer to enter the phone number for the 
fax confirmation by playing the announcement ABC-4-1: 

(voice) Please enter the fax umber with the area code. This will result in a $1 .00 charge to your account you 
transferred funds to. 

[0048] The customer enters the fax number. The front end system identifies the "*0" sign and formats an input mes- 
sage to the bank according to the ABC-4-1 input message format. The message takes the form of: 2 bytes indicating 
a fax confirmation, 2 bytes indicating the customer's selection, and 10 bytes indicating the customer's fax number. The 
bank then instructs the front end system to originate an output message in output message format 16. The first 2 bytes 
of the output message indicates the service to be performed by the front end system - in this case #1 6 indicates text- 
to-fax service. The next 4 bytes indicates the length of the text to be converted - in this case XX bytes. The last XX 
bytes contain the text to be converted. 

[0049] The front end system plays the main menu again, in response to the "0" indication in the "*0" sign and the 
sequence of operations continues according to the profile. 

[0050] FIGs. 3A and 3B make up a flow chart that shows the steps taken by the front end system in processing 
communications with the subscriber. As shown in FIG. 3A, the front end system must first obtain a transaction request 
from the transaction manager (step 120). Such a request will be generated whenever the CTP record indicates that 
an input message will be sent to the subscriber from the front end system, or that an output message is to be sent from 
the subscriber to the front end system. After receiving a transaction request, the front end system queries as to whether 
or not a new transaction is being initiated (step 122). If a new transaction is being initiated, the CTP record associated 
with the transaction must be loaded into the front end system's main memory, or "processing buffer" (step 124). If the 
transaction request is part of an old transaction, it may be processed using the CTP record currently in the processing 
buffer. 

[0051] Once the correct CTP record is loaded into the processing buffer, the front end system proceeds to identify 
the message type called for by the request, either an input message or output message (step 126). After the message 
type is identified (step 126), the appropriate processing "branch" is entered (step 128). 

[0052] When an input message is requested, the input message branch is entered and the front end system takes 
the following steps. First, the front end system collects the business data to be sent to the subscriber (step 130). In 
the bank-customer example, the business data to be sent might be a bank account number. Next, the business data 
is then formatted according to the input message format supplied in the CTP record (step 132). The interface handler 
is then activated and the input message is sent to the subscriber (step 134). At this point front end system processing 
of the input message is complete (step 136). 
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[0053] When an output message is requested, the front end system enters the output message "branch" of the flow 
chart. As a first step in processing an output message, the front end system reads the service code from the output 
message (step 138). Based on this service code, the front end system accesses the CTP record and locates the 
corresponding output message format. The front end system uses its knowledge of the format to parse the business 

s data from the output message (step 140). It then activates any network servers that it will need to carry out the service 
requested in the output message (step 142) and collects responses from those servers (step 144). At this point, the 
front end system inquires as to whether or not an input message will immediately follow completion of the output 
message service (step 146). If an immediate input message is required, the input message branch will entered. If an 
input message is not required, the front end system's processing of the output message is complete (step 148). 

10 [0054] FIG. 4 shows one configuration of front end system software modules and network servers that may be used 
to implement the present invention. As shown in FIG. 4, the interface between a subscriber and the front end system 
includes two software modules, an interface handler 90, and a transaction manager 92. The interface handler performs 
the signal processing necessary to enable the front end system to communicate using standard Open Systems Inter- 
connection (OSI) protocols. The transaction manager performs the task of identifying the subscriber associated with 

15 each transaction request. 

[0055] After each transaction request has been associated with a subscriber, the nature of the requests are docu- 
mented by a transaction request parser 94. This documentation is used by an Input/Output message analyzer 96 to 
access the CTP 98 and obtain the information necessary to process the request. If the request requires the collection 
or generation of business data, a business data processor 100 handles these tasks. The processor 100 may not be 

20 capable of providing all the collection and generation services required, however, it may delegate tasks to one or more 
network servers. 

[0056] The business data processor 100 is shown as having access to three different servers, an image processor 
102, a text to speech server 104, and an announcement server 106. The announcement server is coupled to an an- 
nouncement database 1 08. The database may be used to store a plurality of predetermined subscriber announcements 
25 which can be readily recalled from the database by the announcement server. After collection and generation of the 
business data is complete, the data is passed to a response handler 110. The response handler 110 organizes the 
data and prepares it for transmission by the interface handler. 
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THE CTP 

Subscriber ID Number 



USED IN THE BANK -CUSTOMER EXAMPLE 



Customer Business Transaction Specifications: 
ABC-0(1,2,3,4) 



ABC-1-K0-99999999) 
ABC-1-2 (0-999) *0 

ABC-3-K0-99999999) 
ABC-3-2 (0-99999999) 
ABC-3-3 (0-99999999) *4 

ABC-4(1,2,3) 
ABC-4-l*0 
ABC-4-2 
ABC-4-3 



/* Numbers in 0 are the valid 
inputs 



Range for the account number 

Range for the PIN 
message expected, 
go back to main menu 



go to ABC-4 after sending 
message 



Input Messages: 

ABC-1-2: (2,2,10,10) /* size of each field in the message 

(Query Bank, selection, account #, PIN #) /* field definition 

ABC-3-3: (2,2,10,10,10) 

(Fund Xfer, selection, acnt # from, acnt # to, xfer amount) 



ABC-4-1: (2,2,10) 

(Fax confirm, selection, fax number) 
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Outpuc Messages: /* service numbers noc specified are not 
processed 



15: (2, 4, xx) /* size of each filed for action code #15 
(Action, Length of Text, Text) /*field definition 

16 : (2, 4, XX) 

{Action, Length of Text, Text) 



Other Characteristics for the Transaction Profile {to be 
further customized) . 



Claims 

1 . A method of customizing a network communication protocol, comprising the steps of: 

a) defining one or more customer transaction profiles (98) for a subscriber to said network, each of said profiles 
being associated with a unique subscriber identification number; 

b) storing said customer transaction profiles in a database (15); 

c) assigning one of said unique subscriber identification numbers to a communication session initiated on said 
network; 

d) using said assigned subscriber identification number to determine a matching customer transaction profile 
for said communication session; 

e) accessing said database to retrieve said matching customer transaction profile; 

f) using said matching profile to govern the flow of communications during said communication session; 

g) forming a communication packet (48) according to a message format that is specified within said matching 
customer transaction profile; and 

h) transmitting said communication packet using a standard packet switching protocol. 

2. The method according to claim 1 , wherein the step of using said matching profile to govern the flow of communi- 
cations during said communication session comprises the steps of: 

appending a packet header (68) to said communication packet. 

3. The method according to claim 2, wherein the step of appending a packet header to said communication packet 
comprises the steps of: 

creating an X.25 packet header; and 

appending said X.25 packet header to said communication packet. 

4. The method according to claim 2, wherein the step of appending a packet header to communication packet com- 
prises the steps of: 

creating an ISDN-PRI packet header; and 



9 



EP 0 720 341 B1 



appending said ISDN-PRI packet header to said communication packet. 

5. The method according to claim 1 , further comprising the step of: 

5 modifying said customer transaction profile in response to a request from said subscriber to alter the commu- 

nication flow. 

6. An apparatus for providing customizable protocols to users of a communication network, comprising: 

10 a) a database (1 5) for storing one or more customer transaction profiles (98), each said profile being associated 

with a unique subscriber identification number; 

b) a front end system (50) for assigning one of said subscriber identification numbers ID to a communication 
session initiated on said network (58), said assigned subscriber ID being used to determine a matching cus- 
tomer transaction profile for said communication session, said matching profile being retrieved from said da- 

15 tabase and used to manage the flow of communications during said communication session; 

c) front end formatting apparatus formatting a communication packet (48) according to a message format that 
is specified within said matching customer transaction profile; and 

d) front end transmitting apparatus transmitting said communication packet using a standard packet switching 
protocol. 

20 

7. The apparatus according to claim 6, wherein said unique subscriber identification number comprises a telephone 
number (64a-641). 

8. The apparatus according to claim 6, wherein each of said customer transaction profiles comprises: 

25 

one or more message formats (48) that define the format of communications between said subscriber and 
said network; and 

one or more instructions to control the communication flow between said subscriber and said network. 

30 9. The apparatus according to claim 6, wherein each of said customer transaction profiles comprises: 

one or more input message formats; 
one or more output message formats; and 

one or more instructions to control the communication flow between said subscriber and said network. 

35 

10. The apparatus according to claim 9, wherein each of said one or more input message formats and each of said 
one or more output message formats comprises: 

one or more field sizes; and 
40 one or more field definitions. 

11. The apparatus according to claim 6, further comprising: 

means (24) for coupling said front end system to said subscriber. 

45 

12. The apparatus according to claim 6, further comprising: 

means (14) for coupling said database to said front end system. 
50 13. The apparatus according to claim 10, wherein said front end system comprises a computer (100). 

14. The apparatus according to claim 6, further comprising: 

means (10) for modifying said customer transaction profiles. 

55 

15. The apparatus of claim 6, further comprising: 

e) the front end system having a disk memory (14) for storing said customer transaction profiles (98), a main 
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memory (1 6) into which one or more of said customer transaction profiles can be loaded to create one or more 
loaded profiles; and 

f) a means for using said loaded profiles to control the communication flow over said network. 

5 1 6. The apparatus according to claim 1 5, wherein each of said unique subscriber identification numbers comprises a 
telephone number (64a-641). 

17. The apparatus according to claim 15, wherein each of said customer transaction profiles comprise: 

10 one or more message formats (48) that define the format of communications between said subscriber and 

said network (58), each of said one or more message formats including one or more field sizes and one or 
more field definitions; and 

one or more instructions to control the flow of communications over said network. 
15 18. The apparatus according to claim 15, further comprising: 

means (24) for coupling said front end system to said subscriber. 

19. The apparatus according to claim 15, wherein said front end system is a computer (100). 

20 

20. The apparatus according to claim 15, further comprising: 

means (10) for modifying said customer transaction profiles. 

25 

Revendications 

1. Precede de personnalisation d'un protocole de communication de reseau, comprenant les etapes : 

30 a) de definition d'un ou plusieurs profils de transactions d'abonne (98) pour un abonne audit reseau, chacun 

desdits profils etant associe a un numero d'identification d'abonne unique ; 

b) de memorisation desdits profils de transactions d'abonne dans une base de donnees (15) ; 

c) d'attribution d'un desdits numeros d'identification d'abonne uniques a une session de communication lancee 
sur ledit reseau ; 

35 d) d'utilisation dudit numero d'identification d'abonne attribue afin de determiner un profil de transaction d'abon- 

ne concordant pour ladite session de communication ; 

e) d'acces a ladite base de donnees afin de recouvrer ledit profil de transaction d'abonne concordant ; 

f) d'utilisation dudit profil concordant afin de regir le flux de communications durant ladite session de 
communication ; 

40 g) de formation d'un paquet de communication (48) conformement a un format de message qui est specifie 

dans ledit profil de transaction d'abonne concordant ; et 

h) de transmission dudit paquet de communication au moyen d'un protocole de commutation par paquets 
standard. 

45 2. Precede selon la revendication 1, dans lequel I'etape d'utilisation dudit profil concordant afin de regir le flux de 
communications durant ladite session de communication comprend les etapes : 

d'ajout d'un paquet d'en-tete (68) audit paquet de communication. 

50 3. Precede selon la revendication 2, dans lequel I'etape d'ajout d'un en-tete de paquet audit paquet de communication 
comprend les etapes : 

de creation d'un en-tete de paquet X.25 ; et 

d'ajout dudit en-tete de paquet X.25 audit paquet de communication. 

55 

4. Precede selon la revendication 2, dans lequel I'etape d'ajout d'un paquet d'en-tete au paquet de communication 
comprend les etapes : 
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de creation d'un en-tete de paquet RNIS-PRI ; et 

d'ajout dudit en-tete de paquet RNIS-PRI audit paquet de communication. 

5. Precede selon la revendication 1 , comprenant en outre I'etape : 

de modification dudit profil de transaction d'abonne en reponse a une demande dudit abonne afin de changer 
le flux de communication. 

6. Dispositif pour fournir des protocoles personnalisables a des utilisateurs d'un reseau de communication, 
comprenant : 

a) une base de donnees (15) pour memoriser un ou plusieurs profils de transactions d'abonne (98), chaque 
dit profil etant associe a un numero d'identification d'abonne unique ; 

b) un systeme frontal (50) pour attribuer I'un desdits numeros d'identification d'abonne ID a une session de 
communication lancee sur ledit reseau (58), ladite ID d'abonne attribute etant utilisee pour determiner un 
profil de transaction d'abonne concordant pour ladite session de communication, ledit profil concordant etant 
recouvre depuis ladite base de donnees et utilise afin de gerer le flux de communications durant ladite session 
de communication ; 

c) un dispositif de formatage frontal formatant un paquet de communication (48) conformement a un format 
de message qui est specifies dans ledit profil de transaction d'abonne concordant ; et 

d) un dispositif de transmission frontal transmettant ledit paquet de communication au moyen d'un protocole 
de commutation par paquets standard. 

7. Dispositif selon la revendication 6, dans lequel ledit numero d'identification d'abonne unique comprend un numero 
de telephone (64a a 641). 

8. Dispositif selon la revendication 6, dans lequel chacun desdits profils de transactions d'abonnes comprend : 

un ou plusieurs formats de message (48) qui definissent le format des communications entre ledit abonne et 
ledit reseau ; et 

une ou plusieurs instructions pour commander le flux de communication entre ledit abonne et ledit reseau. 

9. Dispositif selon la revendication 6, dans lequel chacun desdits profils de transactions d'abonnes comprend : 

un ou plusieurs formats de message d'entree ; 
un ou plusieurs formats de message de sortie ; et 

une ou plusieurs instructions afin de commander le flux de communication entre ledit abonne et ledit reseau. 

10. Dispositif selon la revendication 9, dans lequel chacun desdits un ou plusieurs formats de message d'entree et 
chacun desdits un ou plusieurs formats de message de sortie comprend : 

une ou plusieurs tailles de champs ; et 
une ou plusieurs definitions de champs. 

11. Dispositif selon la revendication 6, comprenant en outre : 

un moyen (24) pour coupler ledit systeme frontal audit abonne. 

12. Dispositif selon la revendication 6, comprenant en outre : 

un moyen (14) pour coupler ladite base de donnees audit systeme frontal. 

13. Dispositif selon la revendication 10, dans lequel ledit systeme frontal comprend un ordinateur (100). 

14. Dispositif selon la revendication 6, comprenant en outre ; 

un moyen (10) pour modifier lesdits profils de transactions d'abonne. 

15. Dispositif selon la revendication 6, comprenant en outre : 



12 



EP 0 720 341 B1 

e) le systeme frontal ayant une memoire a disques (14) pour memoriser lesdits profils de transactions d'abonne 
(98), une memoire principale (16) dans laquelle un ou plusieurs desdits profils de transactions d'abonne peu- 
vent etre charges afin de creer un ou plusieurs profils charges ; et 

f) un moyen pour utiliser lesdits profils charges afin de commander le flux de communication sur ledit reseau. 

16. Dispositif selon la revendication 15, dans lequel chacun desdits numeros d'identification d'abonne uniques com- 
prend un numero de telephone (64a a 641 ). 

17. Dispositif selon la revendication 15, dans lequel chacun desdits profils de transactions d'abonnes comprend : 

un ou plusieurs formats de message (48) qui definissent le format des communications entre ledit abonne et 
ledit reseau (58), chacun desdits un ou plusieurs formats de message comportant une ou plusieurs tailles de 
champs et une ou plusieurs definitions de champs ; et 

une ou plusieurs instructions afin de commander le flux de communications sur ledit reseau. 

18. Dispositif selon la revendication 15, comprenant en outre : 

un moyen (24) pour coupler ledit systeme frontal audit abonne. 

19. Dispositif selon la revendication 15, dans lequel ledit systeme frontal est un ordinateur (100). 

20. Dispositif selon la revendication 15, comprenant en outre ; 

un moyen (10) pour modifier lesdits profils de transactions d'abonne. 

Patentanspriiche 

1. Verfahren zum individuellen Anpassen eines Netzwerkkommunikationsprotokolls, das die folgenden Schritte auf- 
weist: 

a) Definition eines Kundentransaktionsprofils oder mehrerer Kundentransaktionsprofile (98) fur einen Abon- 
nenten des Netzwerks, wobei jedes Profil einer eindeutigen Abonnenten-ldentifikationsnummer zugeordnet 
ist; 

b) Speichern der Kundentransaktionsprofile in einer Datenbank (15); 

c) Zuteilen einer der eindeutigen Abonnenten-ldentifikationsnummern zu einer im Netzwerk begonnenen Kom- 
munikationssitzung; 

d) Verwenden derzugeteilten Abonnenten-ldentifikationsnummerzum Bestimmen eines passenden Kunden- 
transaktionsprofils fur die Kommunikationssitzung; 

e) Zugriff auf die Datenbank, urn das passende Kundentransaktionsprofil abzurufen; 

f) Verwenden des passenden Profils, urn den Kommunikationsfluss wahrend der Kommunikationssitzung zu 
regeln; 

g) Bilden eines Kommunikationspakets (48) entsprechend einem Nachrichtenformat, das innerhalb des pas- 
senden Kundentransaktionsprofils spezifiziert ist; und 

h) Ubertragen des Kommunikationspakets unter Verwendung eines genormten Paketvermittlungsprotokolls. 

2. Verfahren nach Anspruch 1 , wobei der Schritt der Verwendung des passenden Profils, urn den Kommunikations- 
fluss wahrend der Kommunikationssitzung zu regeln, die folgenden Schritte aufweist: 

Anhangen eines Paketheaders (68) an das Kommunikationspaket. 

3. Verfahren nach Anspruch 2, wobei der Schritt des Anhangens eines Paketheaders an das Kommunikationspaket 
die folgenden Schritte aufweist: 

Erzeugen eines X.25-Paketheaders; und 

Anhangen des X.25-Paketheaders an das Kommunikationspaket. 

4. Verfahren nach Anspruch 2, wobei der Schritt des Anhangens eines Paketheaders an das Kommunikationspaket 
die folgenden Schritte aufweist: 
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Erzeugen eines ISDN-PRI-Paketheaders; und 

Anhangen des ISDN-PRI-Paketheaders an das Kommunikationspaket. 

5. Verfahren nach Anspruch 1 , das weiter den folgenden Schritt aufweist: 

Verandern des Kundentransaktionsprofils als Antwort auf eine Forderung des Abonnenten, den Kommunika- 
tionsfluss zu andem. 

6. Vorrichtung zum Liefern individuell anpassbarer Protokolle an Nutzer eines Kommunikationsnetzwerks, die auf- 
weist: 

a) eine Datenbank (15) zum Speichern eines Kundentransaktionsprofils Oder mehrerer Kundentransaktions- 
profile (98), wobei jedes Profil einer eindeutigen Abonnenten-ldentifikationsnummer zugeordnet ist; 

b) ein Front-End-System (50) zum Zuteilen einer der Abonnenten-ldentifikationsnummern ID zu einer Kom- 
munikationssitzung, die im Netzwerk (58) eingeleitet wurde, wobei die zugeteilte Abonnenten-ID verwendet 
wird, urn ein passendes Kundentransaktionsprofil fur die Kommunikationssitzung zu bestimmen, wobei das 
passende Profil aus der Datenbank abgerufen und verwendet wird, urn den Kommunikationsfluss wahrend 
der Kommunikationssitzung zu verwalten; 

c) eine das Front-End formatierende Vorrichtung, die ein Kommunikationspaket gemafi einem Nachrichten- 
format (48) formatiert, das innerhalb des passenden Kundentransaktionsprofils spezifiziert ist; und 

d} eine Front-End-Ubertragungsvorrichtung, die das Kommunikationspaket unter Verwendung eines genorm- 
ten Paketvermittlungsprotokolls ubertragt. 

7. Vorrichtung nach Anspruch 6, wobei die eindeutige Abonnenten-ldentifikationsnummer eine Telefonnummer (64a- 
641)enthalt. 

8. Vorrichtung nach Anspruch 6, wobei jedes der Kundentransaktionsprofile aufweist: 

ein Nachrichtenformat oder mehrere Nachrichtenformate (48), die das Format der Kommunikationen zwischen 
dem Abonnenten und dem Netzwerk definieren; und 

einen Befehl oder mehrere Befehle, urn den Kommunikationsfluss zwischen dem Abonnenten und dem Netz- 
werk zu steuern. 

9. Vorrichtung nach Anspruch 6, wobei jedes Kundentransaktionsprofil aufweist: 

ein Eingangsnachrichtenformat oder mehrere Eingangsnachrichtenformate; 

ein Ausgangsnachrichtenformat oder mehrere Ausgangsnachrichtenformate: und 

einen Befehl oder mehrere Befehle, urn den Kommunikationsfluss zwischen Abonnent und Netzwerk zu steu- 
ern. 

10. Vorrichtung nach Anspruch 9, wobei jedes eine oder mehrere Eingangsnachrichtenformat(e) und jedes eine oder 
mehrere Ausgangsnachrichtenformat(e) aufweist: 

eine oder mehrere Feldgrdfien und 
eine oder mehrere Felddefinitionen. 

11. Vorrichtung nach Anspruch 6, die weiter aufweist: 

Mittel (24) zum Koppeln des Front-End-Systems mit dem Abonnenten. 

12. Vorrichtung nach Anspruch 6, die weiter aufweist: 

Mittel (14) zum Koppeln der Datenbank mit dem Front-End-System. 

13. Vorrichtung nach Anspruch 10, wobei das Front-End-System einen Computer (100) aufweist. 

14. Vorrichtung nach Anspruch 6, die weiter aufweist: 
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Mittel (10) zum Verandern der Kundentransaktionsprofile. 

15. Vorrichtung nach Anspruch 6, die weiter aufweist: 

e) das Front-End-System mit einem Diskettenspeicher (14) zum Speichern der Kundentransaktionsprofile 
(98), einen Hauptspeicher (16), in den eines Oder mehrere der Kundentransaktionsprofile geladen werden 
konnen, urn ein geladenes Profil oder mehrere geladene Profile zu erzeugen, und 

f) eine Einrichtung zur Verwendung der geladenen Profile zur Steuerung des Kommunikationsflusses uber 
das Netzwerk. 

1 6. Vorrichtung nach Anspruch 1 5, wobei jede der eindeutigen Abonnenten-ldentifikationsnummern eine Telefonnum- 
mer (64a-641) enthalt. 

17. Vorrichtung nach Anspruch 15, wobei jedes Kundentransaktionsprofil aufweist: 

ein Nachrichtenformat oder mehrere Nachrichtenformate (48), die das Format der Kommunikationen zwischen 
dem Abonnenten und dem Netzwerk (58) definieren, wobei jedes Nachrichtenformat eine oder mehrere Feld- 
grofien und eine oder mehrere Felddefinitionen aufweist; und 

einen Befehl oder mehrere Befehle zur Steuerung des Kommunikationsflusses uber das Netzwerk. 

18. Vorrichtung nach Anspruch 15, die weiter aufweist: 

Mittel (24) zum Koppeln des Front-End-Systems mit dem Abonnenten. 

19. Vorrichtung nach Anspruch 15, wobei das Front-End-System ein Computer (100) ist. 

20. Vorrichtung nach Anspruch 15, die weiter aufweist: 

Mittel (10) zum Verandern der Kundentransaktionsprofile. 
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FIG. 2 
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FIG. 3 
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FIG. 4 




